The present invention generally relates to the field of service and device discovery in a wireless communication network which does not provide multicast support on the medium access control (MAC) sublayer of the data link control (DLC) layer. It particularly refers to a new system and a corresponding method for improving service and device discovery in a wireless communication network using a protocol based on the Universal Plug and Play (UPnP) standard that runs on top of a TCP/IP-based networking layer.
Universal Plug and Play (UPnP) is a distributed, open networking architecture that offers pervasive peer-to-peer network connectivity of personal computers, intelligent appliances and wireless devices. The UPnP networking architecture specification defines general interoperability mechanisms including, among others, mechanisms for automatic address configuration and mechanisms for service and device discovery which enable self-configuring devices to create an ad-hoc, self-discovering communication system of interoperable network devices. This architecture thus leverages TCP/IP-based communication networks to enable seamless proximity networking in addition to control and data transfer among networked devices, which is particularly advantageous in home and office network environments. UPnP achieves this by defining and publishing a set of UPnP device control protocols which allow networked TCP/IP devices to communicate with each other so as to announce their presence to all other devices on a UPnP-based communication network and to then interoperate in a flexible and predefined fashion. Said UPnP device control protocols are built on open, Internet-based communication standards such as TCP/IP, UDP, HTTP, SSDP, SOAP, GENA and XML, which provide the communication infrastructure for said UPnP networking architecture, and allow networked TCP/IP devices to communicate with each other so as to announce their presence to all other devices on the communication network and then to interoperate in a flexible and predefined fashion. Thereby, UPnP technology can run on any physical medium including e.g. phone lines, power lines (PLC), Ethernet, IR (IrDA), RF (Wi-Fi, Bluetooth) and FireWire. Due to the fact that common base protocols are used on a per-device basis, no extra device drivers are required.
A UPnP networking architecture supports zero-configuration, invisible networking and automatic discovery for a breadth of device categories from a wide range of vendors, whereby a device can dynamically join a network, obtain an IP address, announce its name, convey its capabilities upon request and learn about the presence and the capabilities of other devices. DHCP (Dynamic Host Configuration Protocol) and DNS (Domain Name System) servers are optional and are only used if they are available on the network. However, each device must have a DHCP client and search for a DHCP server when the device is first connected to the network. If no DHCP server is available, the device has to assign an address by itself. In case the device obtains a domain name during the DHCP transaction, e.g. through a DNS server or via DNS forwarding, said device should use this name in subsequent network operations; otherwise, the device should use its IP address.
Although a UPnP networking architecture typically consists of a peer-to-peer network, nodes on the network communicate with each other in a client/server-based manner. Thereby, client terminals that provide a user interface for end users are called “Control Points” (CP), and servers providing a well-defined set of services, each of which corresponding to a functional component of a particular server, are called “Controlled Devices” (CD). When a specific CD is added to the network, the UPnP discovery protocol allows that device to advertise its specific services to the CPs on said network. Similarly, when a CP is added to the network, the UPnP discovery protocol allows that CP to search for CDs of interest on the network. The fundamental message exchange in both cases is a discovery message broadcasted by means of the Simple Device Discovery Protocol (SDDP), that contains a few, essential specifics about said CD, a specific one of its services, e.g. its device type, identifier and a pointer to more detailed information, or functional capabilities a CP wants to control. Thereby, any CD which exposes these device capabilities responds to a specific CP's discovery request by identifying itself to the respective CP. This response contains the URL of an XML device description document which identifies specific services implemented by the CD as well as specific actions and state variables that are supported by each service. By parsing this information, the CP is able to determine the exact capabilities of each CD. This allows a CP to determine if it wants to interact with and control a particular CD. When a new CD is added to the network, it may broadcast an identification notification to the network which informs existing CPs about the fact that a new CD has been added to the network and is available to be controlled. The notification information thereby includes the URL of the new CD's description document.
After a CD has been discovered by a CP, the CP still knows very little about this device. For the CP to learn more about the respective device and its device capabilities or to interact with the CD, said CP has to retrieve said CD's description from the URL provided by the CD in the discovery message. The UPnP description for a CD is usually expressed in XML and includes vendor-specific manufacturer information such as the model name and number, serial number, manufacturer name, URLs to vendor-specific web sites, etc. The description also includes a list of any embedded devices or services as well as URLs for control, eventing, and presentation. For each service, the description includes a list of the commands or actions to which the service responds and parameters or arguments for each action. The description for a service further includes a list of variables modeling the state of the service at run time which are described in terms of their data type, range and event characteristics.
After having retrieved a description of the respective CD, the CP is able to send actions to a particular service of this CD. For this purpose, the CP sends a suitable control message to the control URL for the service (provided in the device description). This control message is also expressed in XML using the Simple Object Access Protocol (SOAP). Like function calls, the service returns any action-specific values in response to the control message. The effects of the action, if any, are modeled by changes in the variables that describe the run-time state of the service.
A UPnP description for a service comprises a list of actions this service responds to and a list of variables modeling the state of said service at run time. When these variables change, updates are published by the service and a CP may subscribe to receive this information. The respective service then publishes updates by sending event messages containing the names of at least one state variable and the current value of said variable(s). These messages are also expressed in XML and formatted using the General Event Notification Architecture (GENA). A special initial event message is sent when a CP first subscribes. This event message contains the names and values for all “evented” variables and allows the subscriber to initialize its model of the state of the service. To support scenarios with multiple CPs, eventing is designed to keep all CPs equally informed about the effects of any action. Therefore, event messages are sent to all subscribers, subscribers receive event messages for all “evented” variables that have changed, and these event messages are sent no matter why a particular state variable has been changed (either in response to a requested action or owing to the fact that the state the service is modeling has been changed).
In case a CD has a URL for presentation, the CP can retrieve a page from this URL, load the page into a web browser and, depending on the capabilities of the page, allow a user to control the device and/or view its device status. The degree to which each of these tasks can be accomplished depends on the specific capabilities of the presentation page and device.
For further information on service and device discovery according to the UPnP standard, the interested reader is referred to the URL http://www.upnp.org.